home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   sci.electronics.design      Electronic circuit design      143,102 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 143,044 of 143,102   
   Don Y to albert@spenarnc.xs4all.nl   
   Re: Call by reference protection   
   23 Feb 26 05:20:15   
   
   From: blockedofcourse@foo.invalid   
      
   On 2/23/2026 4:44 AM, albert@spenarnc.xs4all.nl wrote:   
   > In article <10n9deu$a7ej$1@dont-email.me>,   
   > Martin Brown  <'''newspam'''@nonad.co.uk> wrote:   
   >> On 19/02/2026 22:04, Don Y wrote:   
   >>> [Obdisclaimer:  cc'ing s.e.d only because some of you are no longer   
   >>> subscribed to the list and will likely not see this, otherwise.   
   >>> And, its a substantial change in the API so worth noting.]   
   >>>   
   >>> Using similar mechanisms to those that I use in call-by-value RMIs,   
   >>> I can protect against races for call-by-reference -- throwing an   
   >>> exception or just spinning on any violations on the calling side.   
   >>>   
   >>> Or, I can just let people rely on their own discipline to   
   >>> ensure they don't introduce latent bugs via this mechanism   
   >>> (resorting to call by value universally seems a bad idea   
   >>> for legacy coders).  As these types of races have typically   
   >>> been hard to test for, I suspect it is worth the effort.   
   >>>   
   >>> Any pointers to languages or IDLs that include such qualifying   
   >>> adjectives?   
   >>   
   >> Languages that allow call by reference to be qualified with a const or   
   >> readonly directive so that the routine reading the original object (no   
   >> copy made) is not allowed to alter the it in any way.   
   >>   
   >> Detectable as a compile time fault if you do. Relying on all coders to   
   >> be disciplined is likely to be ahem... disappointing.   
   >>   
   >> I can't be the only one to have seen shops where the journeymen are so   
   >> unskilled that getting C code to compile by the random application of   
   >> casts is the norm. Not written in C but the UK scandalous Horizon PO   
   >> accounting system was written by people of that calibre (thickness).   
   >   
   > Using casts should be forbidden in the code standard.   
   > If you want them, you should get approval from a senior programmer.   
   > He will probably learn you that the cast wasn't necessary.   
      
   It may have been necessary to silence a compiler complaint.   
   But, the "problem" is often an incorrect choice of data type.   
   E.g., ints and pointers.   
      
   Coders often don't think about what the "thing" they are   
   manipulating represents.  And, don't realize the value of   
   using a better data type.   
      
   E.g., I worked on a DBMS where the schema stored hex values as   
   varchar's.  Doing so, allowed errors like "DEADBEEs" to be stored   
   and propagated to the queries that tried to make sense of this.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca