From owner-freebsd-questions@FreeBSD.ORG Sat Jan 14 12:06:10 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5261E106566B for ; Sat, 14 Jan 2012 12:06:10 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id 01A338FC08 for ; Sat, 14 Jan 2012 12:06:09 +0000 (UTC) Received: from r56.edvax.de (port-92-195-26-82.dynamic.qsc.de [92.195.26.82]) by mx02.qsc.de (Postfix) with ESMTP id 19F451E562; Sat, 14 Jan 2012 13:06:07 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id q0EC6747004717; Sat, 14 Jan 2012 13:06:07 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Sat, 14 Jan 2012 13:06:07 +0100 From: Polytropon To: Da Rock Message-Id: <20120114130607.5a444301.freebsd@edvax.de> In-Reply-To: <4F115ADA.5050103@herveybayaustralia.com.au> References: <201201140954.q0E9sOgM037468@mail.r-bonomi.com> <4F115ADA.5050103@herveybayaustralia.com.au> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: access(FULLPATH, xxx); X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 12:06:10 -0000 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@freebsd.org Sat Jan 14 02:32:15 2012 > >> Date: Sat, 14 Jan 2012 09:28:21 +0100 > >> From: Polytropon > >> To: Robert Bonomi > >> Cc: freebsd-questions@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. > 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, ...