access(FULLPATH, xxx);

Da Rock freebsd-questions at
Sat Jan 14 10:42:27 UTC 2012

On 01/14/12 19:54, Robert Bonomi wrote:
>>  From owner-freebsd-questions at  Sat Jan 14 02:32:15 2012
>> Date: Sat, 14 Jan 2012 09:28:21 +0100
>> From: Polytropon<freebsd at>
>> To: Robert Bonomi<bonomi at>
>> Cc: freebsd-questions at
>> 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
> 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... :)

Technically (depending on their era) they're both right. For reference 
as far as the linux lists played out no one won the argument, but it was 
a helluva nostalgic/historical debate!

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).

More information about the freebsd-questions mailing list