access(FULLPATH, xxx);

[Da Rock]

On 01/14/12 22:06, Polytropon wrote:
> 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... :-)
I think the problem these days is a combination of many things.

Firstly, in the old days (I sound like grandpa... :/ ) punch cards were 
hard to do, time consuming, and machine time was very expensive. So 
programmers had to get it right the first time (or close to it), and 
documentation was paramount.

Secondly, in the early years the internet wasn't exactly up and running 
(as such), and so global programming teams weren't a problem with 
language differences (and people were taught far better english and 
speling- whoops spelling :) none of this and other shortenings; 
ambiguity kept to a minimum).

Thirdly, when things did become easier (gcc era?) the documentation 
slipped, and programmers started getting more sloppy, as the mistakes 
were easily fixed. The docs became more ambiguous, and language did 
start slipping (globally- not just in computing).

Fourthly, globalisation occured, internet was up and running on a global 
scale, international teams were working on programs, and people were 
attempting to translate japanese manuals into english (if you catch my 
drift... :) I used to be a Xeroid and this was a standing joke). So not 
all docs were as clear anymore.

Lastly, we have the travesty of a lack of discipline in skills. Near 
enough's good enough, and so on. No one is taking the time anymore to 
become "skilled" - they want it now or never. Take a 6 week course and 
become an expert. The masters and gurus are becoming few and far between 
now (although there appears to be a nice concentration here- thats why I 
stick around. Linux lists seem to have the cranky ones :) ). And so we 
have the case as you have outlined Poly. That said the docs are getting 
to be of not much help either unless you're partly clairvoyant too in 
more cases than should be.

It is not always easy to articulate exactly what something does and how 
it works, but the basics should be there. Given the global society we 
live in with the numerous dialects its a hard task to try to ensure 
everyone will understand precisely. Care needs to be taken to ensure 
everyone does, though, if something in the code will blow something up. 
Ideally, it would be handy to have translators on hand to help with 
documentation projects, but that is not a feasible prospect. Examples 
would probably work better than a thousand words (like a picture)- no 
translation required.

Myself I believe that one needs to read the docs thoroughly and then if 
it is ambiguous then run a test case, if all else fails: ask. But one 
needs to be as exact as possible when doing anything. "Any job worth 
doing is worth doing properly", and "god/devil is in the details" - Is 
say "God _and_ the devil is in the details": if you don't pay attention 
to the details the devil _will_ make sure it bites you in the ass!

Its a crazy world, though, isn't it? :)