Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2796

Re: for or against equality, was Why are ambiguous grammars usually a bad idea?

Show all headers | View raw

On 05/01/2022 11:25, Martin Ward wrote:

> Using a language that you don't know in its entirety might seem
> dangerous, but everybody seems to do it these days:
> how many C programmers have read the entire 500+ pages of
> the latest C standard and memorised the 200+ varieties
> of "undefined behaviour" so that they can avoid all of them
> in every line of code that they write?

I think it is normal not to know everything about the language you use.
 And if you include the language's standard library, then there are very
few currently used languages where it would even be possible to learn it
all.  By the time you learned all of the language and default libraries
of C++, Java, Python, etc., there would be a new version out and you'd
have more to learn.

The important things for writing code are to know enough to be able to
write the kind of code you are doing, and to avoid accidentally doing
things you didn't intend. Static warning tools are vital here - from
syntax-highlighting and check-as-you-type editors and IDE's, through
compiler warning flags, to stand-alone checkers. Your tools should
tell you if you are accidentally using a reserved word as an
identifier.

There is no need to memorize undefined behaviours for a language -
indeed, such a thing is impossible since everything not defined by a
language standard is, by definition, undefined behaviour. (C and C++
are not special here - the unusual thing is just that their standards
say this explicitly.)

The trick is to memorize the /defined/ behaviours, and stick to them.
You generally don't need to know if a language leaves (1 / 0) as
undefined, or gives a specific value, or prints an error message -
usually it is sufficient to know the values for which (x / y) /is/
defined, and stick to those values.

Basically, trying to execute undefined behaviour is no more and no less
than a bug in the program - whether it is "undefined" in terms of the
language, the library, the code you wrote yourself, the customer's
specification, or anything else.  People program primarily by trying to
write correct code - not by trying to think of all the ways they could
write incorrect code!


The real challenge from big languages and big standard libraries is not
/writing/ code, it is /reading/ it.  It doesn't really matter if a C
programmer, when writing some code, does not know what the syntax "void
foo(int a[static 10]);"  means.  (Most C programmers don't know it, and
never miss it.)  But it can be a problem if they have to read and
understand code that uses something they don't know.

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: for or against equality, was Why are ambiguous grammars usually a bad idea? Martin Ward <martin@gkc.org.uk> - 2022-01-05 10:25 +0000
  Re: for or against equality, was Why are ambiguous grammars usually a bad idea? David Brown <david.brown@hesbynett.no> - 2022-01-06 09:11 +0100
    Re: what is defined, was for or against equality Thomas Koenig <tkoenig@netcologne.de> - 2022-01-06 16:43 +0000
      Re: what is defined, was for or against equality David Brown <david.brown@hesbynett.no> - 2022-01-07 12:06 +0100
      Re: what is defined, was for or against equality Spiros Bousbouras <spibou@gmail.com> - 2022-01-07 13:21 +0000
        Re: what is defined, was for or against equality Thomas Koenig <tkoenig@netcologne.de> - 2022-01-08 09:31 +0000
          Re: what is defined, was for or against equality Spiros Bousbouras <spibou@gmail.com> - 2022-01-08 22:28 +0000
            Re: what is defined, was for or against equality Thomas Koenig <tkoenig@netcologne.de> - 2022-01-09 00:09 +0000
              Re: what is defined, was for or against equality Spiros Bousbouras <spibou@gmail.com> - 2022-01-09 21:30 +0000
          Re: what is defined, was for or against equality David Brown <david.brown@hesbynett.no> - 2022-01-09 23:00 +0100
            Re: what is defined, was for or against equality Thomas Koenig <tkoenig@netcologne.de> - 2022-01-10 12:04 +0000
              Re: what is defined, was for or against equality David Brown <david.brown@hesbynett.no> - 2022-01-11 18:16 +0100
                Re: what is defined, was for or against equality Kaz Kylheku <480-992-1380@kylheku.com> - 2022-01-11 19:19 +0000
                Re: what is defined, was for or against equality gah4 <gah4@u.washington.edu> - 2022-01-11 14:18 -0800
                Re: what is defined, was for or against equality Thomas Koenig <tkoenig@netcologne.de> - 2022-01-12 19:02 +0000
                Re: what is defined, was for or against equality David Brown <david.brown@hesbynett.no> - 2022-01-13 08:24 +0100
                Re: what is defined, was for or against equality Thomas Koenig <tkoenig@netcologne.de> - 2022-01-13 11:17 +0000
          Re: what is defined, was for or against equality gah4 <gah4@u.washington.edu> - 2022-01-10 16:58 -0800
    Re: for or against equality, was Why are ambiguous grammars usually a bad idea? Robert Prins <robert@prino.org> - 2022-01-06 19:07 +0000
    Undefined behaviour, was: for or against equality Martin Ward <martin@gkc.org.uk> - 2022-01-07 14:02 +0000
      Re: Undefined behaviour, was: for or against equality Spiros Bousbouras <spibou@gmail.com> - 2022-01-08 03:41 +0000
    Re: Undefined behaviour, was: for or against equality David Brown <david.brown@hesbynett.no> - 2022-01-07 15:56 +0100
      Re: Undefined behaviour, was: for or against equality anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2022-01-08 17:52 +0000
        Re: Undefined behaviour, was: for or against equality David Brown <david.brown@hesbynett.no> - 2022-01-09 23:53 +0100
        Re: Undefined behaviour, was: for or against equality Kaz Kylheku <480-992-1380@kylheku.com> - 2022-01-11 16:55 +0000
          Re: Undefined behaviour, was: for or against equality George Neuner <gneuner2@comcast.net> - 2022-01-11 22:01 -0500

csiph-web