| slovo | definícia |
lossage
(foldoc) | lossage
/los'*j/ The result of a bug or malfunction. This
is a mass or collective noun. "What a loss!" and "What
lossage!" are nearly synonymous. The former is slightly more
particular to the speaker's present circumstances; the latter
implies a continuing lose of which the speaker is currently
a victim. Thus (for example) a temporary hardware failure is
a loss, but bugs in an important tool (like a compiler) are
serious lossage.
[Jargon File]
(1995-04-19)
|
lossage
(jargon) | lossage
/los'@j/, n.
[very common] The result of a bug or malfunction. This is a mass or
collective noun. “What a loss!” and “What lossage!” are nearly synonymous.
The former is slightly more particular to the speaker's present
circumstances; the latter implies a continuing lose of which the speaker
is currently a victim. Thus (for example) a temporary hardware failure is a
loss, but bugs in an important tool (like a compiler) are serious lossage.
|
| | podobné slovo | definícia |
precedence lossage
(foldoc) | precedence lossage
/pre's*-dens los'*j/ A misunderstanding of {operator
precedence} resulting in unintended grouping of arithmetic or
logical operators when coding an expression. Used
especially of mistakes in C code due to the nonintuitively
low precedence of "&", "|", "^", "". For example,
the following C expression, intended to test the least
significant bit of x,
x & 1 == 0
is parsed as
x & (1 == 0)
which is always zero (false).
Some lazy programmers ignore precedence and parenthesise
everything. Lisp fans enjoy pointing out that this can't
happen in *their* favourite language, which eschews precedence
entirely, requiring one to use explicit parentheses
everywhere.
[Jargon File]
(1994-12-16)
|
precedence lossage
(jargon) | precedence lossage
/pre's@·dens los'@j/, n.
[C programmers] Coding error in an expression due to unexpected grouping of
arithmetic or logical operators by the compiler. Used esp. of certain
common coding errors in C due to the nonintuitively low precedence levels
of &, |, ^, (for this reason, experienced C programmers
deliberately forget the language's baroque precedence hierarchy and
parenthesize defensively). Can always be avoided by suitable use of
parentheses. LISP fans enjoy pointing out that this can't happen in their
favorite language, which eschews precedence entirely, requiring one to use
explicit parentheses everywhere. See aliasing bug, memory leak, {memory
smash}, smash the stack, fandango on core, overrun screw.
|
|