access(FULLPATH, xxx);

[Polytropon]

On Sat, 14 Jan 2012 20:37:14 +1000, Da Rock wrote:
> On 01/14/12 19:54, Robert Bonomi wrote:
> >>  From owner-freebsd-questions at freebsd.org  Sat Jan 14 02:32:15 2012
> >> Date: Sat, 14 Jan 2012 09:28:21 +0100
> >> From: Polytropon<freebsd at edvax.de>
> >> To: Robert Bonomi<bonomi at mail.r-bonomi.com>
> >> Cc: freebsd-questions at freebsd.org
> >> Subject: Re: access(FULLPATH, xxx);
> >>
> >> On Sat, 14 Jan 2012 02:00:12 -0600 (CST), Robert Bonomi wrote:
> >>> To repeat some advice from one of my Computer Science professors, many years
> >>> ago, whenever I asked 'how does it work' questions: "Try it and find out."
> >> I bet my professor can beat up your professor. :-)
> >>
> >> Mine used to say several times: "Trial and error is NOT
> >> a programming concept!"
> > As far as writing applications goes, that is _somewhat_ correct.
> >
> > However, 'trial and error' is _not_ the same thing as 'try it and find out'.
> > See the entire subject area of 'benchmarking'.
> >
> > And,  the only way to definitively establish if an alternate approach is
> > 'better' -- i.e. 'faster', or 'smaller', or 'more efficient', etc. -- *IS*
> > to run a trial.
> >
> > Your professor undoubtedly would not of approved when I wrote bubble-sort
> > code that _out-performed_ any other sorting technique -- up to the limits
> > of memory.  Or when I re-wrote an application that used binary searches
> > of records, with a new version that used a brute-force linear search.  I
> > thought I could 'do it better/faster' than the existing code, but the only
> > way to "definitively" find out was to 'try it'.  And the 'trial' proved
> > out -- the replacement code was 'merely' somewhat over 100 times faster.
> > *grin*
> Ha! Love it... :D

Mee too - except that I didn't want to show that
"typical attitude". In fact, I tried to make a
(kinf of humourical) statement about a habit that
I could observe at many students when I was at
university.

Background:

When you write source code, you can make errors.
Compiler shows errors. Some students started
with "trial & error" to just silence the compiler.
One form was that all functional parts of the
program were enclosed in /* and */ (it was a
C class) - no errors, but no action. A different
approach was to arbitrarily (!) change the source
code, something like that:

	void *foo(int blah, void *meow())(int ouch);

Hmmm... gives me segfaults. Maybe something's
wrong with the pointers?

	void *foo(int blah, void **meow())(int ouch);

Not much better, segfaults too. How about that?

	void *foo(int blah, void meow())(int *ouch);

Well... also not better. I've heared about parentheses,
maybe those can help?

	void *foo(int blah), void *meow)(int ouch);

Shit, doesn't even compile anymore! Uhm... _what_ did
I change? Oh wait, I know:

	void *foo(int blah, (void *)meow())(int ouch);

Just produces garbage, then segfaults... what could I
change next?

I think you get the idea.

Other students could not understand that even if a
program compiles without any errors, there _may_ be
the possibility that it doesn't do what they intended
it to do. They seemed to believe in some kind of
magical "semantic compiler":

	int x, y, sum;
	x = 100;
	y = 250;
	sum = a - b;

They expected the compiler to notice what's wrong here
if you consider the _meaning_ of the identifiers. It's
not that obvious if you use x, y, and z. :-)



> > As far as 'doing it once' for the purpose of answering a 'how does it work'
> > question -- where one has _not_ read the documentation, *OR* the existing
> > documentation is _not_clear_, then simple experimentation -- to get *the*
> > authoritative answer -- is entirly justified.
> >
> > When I got the 'try it and find out' advice, I was asking questions about
> > situations where the language _specification_ was unclear -- there were
> > two 'reasonable interpretations' of what the language inthe speciication
> > said, and I just wanted to  know which one was the proper interpretation.
> >
> > Now, given that the language in the specification _was_ abiguous and both
> > interpretations were reasonsble, different compiler builders could have
> > implemented differently, and 'try it and find out' was _necessary_ to
> > establish what that particular implementation did.<grin>
> There appears to be 2 schools of thought on this subject: a classic case 
> of the "old" vs the "new", in this case "punchcards/slow compilers" vs 
> "gcc/all-in-one compile, link and go"of todays tech. I saw a similar 
> conversation about 5 years ago on the linux lists... :)

I didn't want to complain about using a test case,
with determined variables (relative path vs. absolute
path) to see if the interpretation of "man 2 access"
was matching the actual inner workings of the function
in use. In fact, I would even judge this the _preferred_
method to be sure.



> In the light of this conversation and given todays tech I'd say give it 
> a shot unless you think something could break (as in fatal to service 
> quality in production/hardware).

Fully agree. Know your variables and construct a
test within a fixed environment. The result will
be a valid source of conclusion.

Now back to "trial & error": what if I use
brackets instead?

	void *foo(int blah, void *meow[])(int ouch);

Hmmm... :-)



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...