to the next instruction. Only ERESTART should return to
the same instruction. Differences to sparc64 reduced.
Test t_ptrace_wait:syscallemu1 now passes on sparc.
Fixes PR kern/52166 "syscallemu does not work on sparc (32-bit)"
Ok: Martin Husemann
to what the shell produces for tilde expansions, when the expansion
of the tilde prefix ends with '/' and the character immediately following
is another '/' - previously /bin/sh (and most other shells, but not all)
retained both slashes, and this test expected that behaviour.
No longer, now only one of the two will appear. Adjust the expected
test results accordingly, and add an extra loop iteration to make sure
this is thoroughly tested (one more tilde expansion value).
Also, add two new test cases that test for the new (explicit - though
it was always stated this way, but not as explicitly) that if HOME is
an empty string (not unset - that remains an unspecified case, as it
was) then the expansion of ~ must generate "", and not nothing.
The current test was unable to distinguish those two, since it
simply looked for characters in the output, so add a new test cases
explicitly to test for this particular case. This also means (also
previously in the standard, but not as explicitly) that shells are
not permitted to decide "The ~ expansion produces an empty string, that
is weird, let's generate something else instead" which some shells were
doing.
For large integer constants, the resulting type could differ between
traditional C and C90. In C99 mode, this difference is no longer
relevant since it is too far away from traditional C.
The names of the tests were misleading: 'recursive' should have been
'nested', and the interesting topic in the 'cast' tests was not the cast
but the pointer dereference.
Following the C11 grammar, the keyword '_Atomic' needs to be a separate
syntactic category, to avoid further conflicts in the grammar.
The two newly added conflicts in the grammar would come into play when
mixing traditional C with C11, in a type name without an implicit 'int'.
If the type '_Atomic(int)*' were parsed as '_Atomic int(int)*', the
trailing '*' would be a syntax error.
And make the tests work, and exercise all lengths up to 100.
Evidently the previous definition, presumably tightly optimized for
1980s-era compilers and CPUs, was too hard to understand, because it
was incorrectly tested for two decades and broken for years.
PR lib/57141
XXX pullup-8
XXX pullup-9
XXX pullup-10
process scheduling works. That a process (or in this case,
a thread) is no longer blocked at time T does not mean that it
will resume execution at time T. The OS is free to devote
resources to other processes/threads instead - all we should
normally be able to expect is that if it is not unblocked before
time T, that it will not start running before then.
In general though, the pthread_cond_*wait() functions don't guarantee
even that - but for this test, the possibility of something else
randomly signalling the condvar isn't believable, so don't worry about
that possibility (but do fail without calling strerror(0) on the off
chance it does happen).
Once we cease testing that the process resumed running before some
particular time, we can stop dealing with qemu timekeeping issues,
it might (seem to) take qemu twice as long as was requested before
the thread resumes, but that's OK - the same thing could happen on
a loaded system for other reasons.
Beyond that, the test also has (had) a race condition. When using
CLOCK_REALTIME though that clock needed to have advanced to T before
the ETIMEDOUT should happen, there is no guarantee that it will stay >T
(CLOCK_REALTIME is allowed to be reset backwards). So, only test
that the current time (after ETIMEDOUT) >= T when we're using
CLOCK_MONOTONIC - for CLOCK_REALTIME the time might have stepped
back between when the ETIMEDOUT happened and when the thread
obtains the current clock reading. For that case, all we can test
is that the ETIMEDOUT actually happens.
With much of what was there now gone, the code can be simplified,
we no longer need to do timespec arithmetic, just one comparison
(simpler to test that Tend >= Tstart+period than Tend-Tstart > period
as we need Tstart+period for the abstime value for the timeout anyway).
Note that this still tests for the issue reported in PR lib/47703
which is where the test came from in the first place.
ps: we seem to be missing pthread_cond_clockwait() which is the same
as pthread_cond_timedwait() except that the clock to use is passed
as a parameter, rather than as an attribute of the condition variable.
To test e.g., the file "/some/where/protocols" instead of "/etc/protocols",
set TEST_FILE=/some/where/protocols in your environment.
Note: this now compares the contents of the file you gave versus what
getprotoent(3)/getservent(3) uses (which still is /etc/protocols via
h_protoent.c / /etc/services or /var/db/services.cdb via h_servent.c).
When you have expected changes in the services or protocols file that
you're generating, this necessarily produces a difference. To really
allow testing the file versus what the library function returns, you'd
have to install the file on the system running the test, but at least
with this change you can now generate the file and verify that it didn't
caused unexpected differences.
for native /dev and create an alias for disk devices w/o partition
latter pointing at the raw partition, so for rump based tests we
actually have to calculate the concrete device name.
Use an idiom suggested by kre for this which also works for ports that
have kern.rawpartition > 4.
the secondary GPT header is moved. Do it this way rather than
just using -q to suppress the message, so the test verifies that
the appropriate action was taken.
As of:
commit 36c52a52eecf1ed0232f9e138564009a85de76c2
Author: Jonathan T. Looney <jtl@FreeBSD.org>
Date: Sat Nov 14 15:44:28 2020 +0000
Add a regression test for the port-selection behavior fixed in r367680.
disabling support in UFS2 for extended attributes (including ACLs).
Add a new variant of UFS2 called "UFS2ea" that does support extended attributes.
Add new fsck_ffs operations "-c ea" and "-c no-ea" to convert file systems
from UFS2 to UFS2ea and vice-versa (both of which delete all existing extended
attributes in the process).
correct so make the expected return ERR then repeat the call with
scrollok set to true to validate.
Do refreshes on the window instead of stdscr so we get the window
contents reported and update the check files with the expected
output.
error: queries.c(118): missing /* expect+1: implicit conversion
changes sign from 'char' to 'int' [Q3] */
error: queries.c(122): missing /* expect+1: implicit conversion
changes sign from 'char' to 'int' [Q3] */
Declaring an array type having a negative dimension is the simplest way
to embed an integer into a lint diagnostic, thereby revealing what size
and alignment lint has calculated for a struct.
While here, move these "compile-time assertions" closer to their
corresponding struct, to make reading easier.
In the kernel, several structs have this attribute, and running lint on
them runs into a compile-time assertion. Typical error messages are:
* error: illegal bit-field size: 255 [36]
* error: integral constant expression expected [55]
Most GCC attributes consist of a single identifier. Up to now, it was
necessary to list each of these identifiers in the grammar, even those
that only apply to a single target architecture.
Instead, parse the general form of attributes, matching the few
attributes that lint handles by name instead. While here, rename the
grammar rules to use the GCC terms.
To avoid conflicts between the global function 'printf' and the GCC
attribute of the same name, do not add GCC attributes to the symbol
table, and don't make these symbols 'extern' either.
ok christos@.
cgdconfig: getfsspecname failed: no match for `wd0e'
as the virtual machine has root on dk0, dk0 at wd0 and trying to
open wd0e fails.
This tests runs without a rump kernel and therefore should not
even try to open configured devices on the host. Replace the
disks "wd0e" and "ld1e" with non-existant disks "dska" and "dskb".
New clause `shared <id> algorithm <alg> subkey <info>' in a keygen
block enables `cgdconfig -C' to reuse a key between different params
files, so you can, e.g., use a single password for multiple disks.
This is better than simply caching the password itself because:
- Hashing the password is expensive, so it should only be done once.
Suppose your budget is time t before you get bored, and you
calibrate password hash parameters to unlock n disks before you get
bored waiting for `cgdconfig -C'.
. With n password hashings the adversary's cost goes up only by a
factor of t/n.
. With one password hashing and n subkeys the adversary's cost goes
up by a factor of n.
And if you ever add a disk, rehashing it will make `cgdconfig -C'
go over budget, whereas another subkey adds negligible cost to you.
- Subkeys work for other types of keygen blocks, like shell_cmd,
which could be used to get a key from a hardware token that needs a
button press.
The <info> parameter must be different for each params file;
everything else in the keygen block must be the same. With this
clause, the keygen block determines a shared key used only to derive
keys; the actual key used by cgdconfig is derived from the shared key
by the specified algorithm.
The only supported algorithm is hkdf-hmac-sha256, which uses
HKDF-Expand of RFC 5869 instantiated with SHA-256.
Example:
algorithm aes-cbc;
iv-method encblkno1;
keylength 128;
verify_method none;
keygen pkcs5_pbkdf2/sha1 {
iterations 39361;
salt AAAAgMoHiYonye6KogdYJAobCHE=;
shared "pw" algorithm hkdf-hmac-sha256
subkey AAAAgFlw0BMQ5gY+haYkZ6JC+yY=;
};
The key used for this disk will be derived by
HKDF-HMAC-SHA256_k(WXDQExDmBj6FpiRnokL7Jg==),
where k is the outcome of PBKDF2-SHA1 with the given parameters.
Note that <info> encodes a four-byte prefix giving the big-endian
length in bits of the info argument to HKDF, just like all other bit
strings in cgdconfig parameters files.
If you have multiple disks configured using the same keygen block
except for the info parameter, `cgdconfig -C' will only prompt once
for your passphrase, generate a shared key k with PBKDF2 as usual,
and then reuse it for each of the disks.
Note that realpath can act differently for root than for other users
(where an ordinary user will see EACCESS root just barrels right through).
The tests adapt themselves, when run as root, less error cases can be
tested than when run as some other user.
The previous message 'may cause alignment problem' was not detailed
enough to be actionable, it didn't give the necessary insight to why
lint was complaining at all.
The new message 'increases alignment from 1 to 4' or 'from 2 to 8'
describes the potentially problematic conversion, and together with the
involved type names, it allows an informed decision about whether lint's
warning is warranted or not.
In a typical NetBSD build, this warning is in the top 10. The number of
these warnings depends on the architecture, it is typically between 800
and 1600.
Casting from and to _Bool is only allowed outside strict bool mode.
Outside strict bool mode, _Bool is an integer type, therefore return
early if any of the operands has type _Bool. In strict bool mode, even
casting from _Bool to _Bool is not allowed, as it is not needed in
practice.
Handle _Complex types before real floating-point types. Return early
for _Complex types, as these are floating-point types as well.
For pointer casts, not only flag casts to or from 'pointer to void', but
also casts between the same types.
In debug mode, when constructing the type '_Complex float', the type
name of '_Complex' occurs in the debug log. Outside of debug mode,
printing this type name is an error since this type keyword only occurs
internally, when constructing a type. At that point, it is not supposed
to occur in any user-visible message.
The possible values of the expression 'a % b' for unsigned integers lie
between 0 and (b - 1). For signed integers, it's more complicated, so
ignore them for now.
For unsigned integers, the possible range of the result can be narrowed
down by looking at the right operand of the '%'. Right now, lint
doesn't do this though.
In the last 18 months, several lint warnings have been made adjusted to
allow common usage patterns. For example, lint no longer warns about a
constant condition in the statement 'do { ... } while (false)' (message
161), as this pattern is well-known in statement-like macros, making it
unlikely that the 'false' is a mistake. Another example is casts
between unequal pointer types (message 247) for a few well-known
patterns that are unlikely to be bugs.
Occasionally, it is useful to query the code for patterns or events that
would not justify a warning. These patterns are modeled as predefined
queries that can be selected individually, in addition to and
independently of the existing warnings and errors.
New queries can be added as needed, in the same way as new warnings.
Queries that are deemed no longer used can be deactivated in the same
way as warnings that are no longer used.
As long as none of the queries is enabled, they produce a minimal
overhead of querying a single global variable. Computations that are
more expensive than a few machine instructions should be guarded by
any_query_enabled.
https://mail-index.netbsd.org/source-changes-d/2022/06/28/msg013716.html
ok christos@
build_bit_shift converts the right-hand operand to INT or UINT, even
though C11 6.5.7 doesn't say anything about narrowing conversions.
Traditional C says that the operators '<<' and '>>' perform the usual
arithmetic conversions. This has been dropped in C90.
What lint actually does is something completely different. In the
operators table in ops.def, the operators '<<' and '>>' are not marked
as performing the usual arithmetic conversions (column 'balance'). This
leaves all conversions to 'build_bit_shift', which converts the
right-hand side to INT or UINT. There is no obvious reason for this
conversion, as the bounds checks need to be performed no matter whether
the type is INT or UINT128.
Message 138 doesn't occur in practice, it was the last one that was
missing the quotes around the placeholder.
Message 240 was also missing the quotes, but it was not reachable. There
was also no apparent benefit in warning about 'assignment of different
structures' when the message about 'assignment type mismatch' serves the
same purpose.
If the (recursive) element type of the array is compatible, that's good
enough. Even after the previous commits, this warning is the one that
occurs most in a standard NetBSD build, and it is generally ignored.
For now, focus on reducing the number of false positives to an
acceptable level.
Casting a 'pointer to char' to a 'pointer to anything else' is already
allowed, except for 'pointer to struct/union'. The cause for this
inconsistency is the wrong order of checks in
'should_warn_about_pointer_cast'.
Reword some of the messages slightly, exchanging brevity for clarity.
Message 138 is kept as-is, as it is not yet covered by any tests.
Message 240 is kep as-is, as it is unreachable.
Now that each lint1 test lists all generated diagnostics as 'expect'
comments, the information from the .exp files is no longer needed. The
only information that gets lost is the order of the diagnostics, which
is mostly relevant for paired messages like 'inconsistent definition' +
'previous definition was here'.
Previously, the expectations from these comments were already satisfied
if the expectation occurred somewhere in the actual message from lint.
This meant that the prefix 'error:' or 'warning:' could be omitted from
the 'expect' comment. These omissions were hard to see in a manual
review. Now any omissions must be visually marked with '...'.
The test msg_342 now reports its messages properly as being in the file
msg_342.c, rather than msg_341.c. This had been a copy-and-paste
mistake.
Enough time has passed since I wrote that little program to make me
forget the naming scheme I had in mind back then. Prefix the variable
names with the source of their data, 'c_' or 'exp_', to provide a bit of
orientation.
No functional change.
Only the tests in msg_*.c had used the short form of the 'expect:'
comments. The other tests used the more detailed variant 'expect+n:' or
'expect-n:'.
The 'expect+-' comments provide more context, which makes it easier to
read the .c files on their own, without having to look up the actual
diagnostics in the .exp files.
Add tests for messages 105 and 106, which were about the obscure feature
of some traditional C compilers that allowed the expression 'x->member'
to access a struct member, even if 'x' had integer type.
The remaining tests will be migrated in a future commit.
The test had been wrong since msg_132.c 1.14 from 2022-05-30.
Using 'unsigned long' in a test that was intended to behave the same on
ILP32 and LP64 was an accident. Use 'unsigned long long' instead, which
is 64-bits wide on all platforms supported by lint.
Move the test about conversion from 'long' to 'int' to the
platform-specific test files.
Noticed by martin@ on powerpc.
allow conditionally disabling the building of certain user space
programs in the 'base' set.
There is not enough consensus that this is the right way and a few
people had strong objections, see source-changes-d@.
This was introduced two years ago when the getrandom/getentropy API
question was still open, and removed because the discussion was
ongoing. Now getentropy is more widely adopted and soon to be in
POSIX. So reintroduce the symbol into libc since we'll be keeping it
anyway. Discussion of details of the semantics, as interpreted by
NetBSD, is ongoing, but the symbol needs to get in before the
netbsd-10 branch. The draft POSIX text is
(https://www.opengroup.org/austin/docs/austin_1110.pdf):
SYNOPSIS
#include <unistd.h>
int getentropy(void *buffer, size_t length);
DESCRIPTION
The getentropy() function shall write length bytes of data
starting at the location pointed to by buffer. The output
shall be unpredictable high quality random data, generated by
a cryptographically secure pseudo-random number
generator. The maximum permitted value for the length
argument is given by the {GETENTROPY_MAX} symbolic constant
defined in <limits.h>.
RETURN VALUES
Upon successful completion, getentropy() shall return 0;
otherwise, -1 shall be retunred and errno set to indicate the
error.
ERRORS
The getentropy() function shall fail if:
[EINVAL] The value of length is greater than
{GETENTROPY_MAX}.
The getentropy() function may fail if:
[ENOSYS] The system does not provide the necessary
source of entropy.
RATIONALE
The getentropy() function is not a cancellation point.
Minor changes from the previous introduction of getentropy into libc:
- Return EINVAL, not EIO, on buflen > 256.
- Define GETENTROPY_MAX in limits.h.
The declaration of getentropy in unistd.h and definition of
GETENTROPY_MAX in limits.h are currently conditional on
_NETBSD_SOURCE. When the next revision of POSIX is finalized, we can
expose them also under _POSIX_C_SOURCE > 20yymmL as usual -- and this
can be done as a pullup without breaking existing compiled programs.
Found by afl, starting with the malformed input '/**/f=({;/**/};}' that
no longer crashes. This input led to 'f=({L:;}', which is at least a
syntactically valid prefix of a translation unit, containing a GCC
statement expression with an unused label. The error message for this
unused label assumed that it would always be inside a function
definition.
While here, document incomplete recovery after syntax errors, in
msg_249.c.
Since tree.c 1.444 from 2022-05-26, which added range and bit checks for
integer expressions, not taking into account that querying for the size
of a bit-field type triggers an error message.
The expression 'any & 0xff' can always be assigned to 'uint8_t' without
loss of any value bits. In the same way, '(any & 0xff) << 8' can always
be assigned to 'uint16_t'.
Previously, lint warned about these cases. Fix these wrong warnings by
tracking the possible values of integer expressions across a single
expression.
Fixes PR 36668, so that <sys/endian.h> does not need to be cluttered
with useless casts anymore.
When a system header defined the constant FALSE = 0, that constant could
be passed as a bool argument. On the other hand, the constant TRUE = 1
could not be passed in the same way. Remove this inconsistency.
This allows expressions like '__alignof__(ptr)->member', just as with
'sizeof'.
The upper rule in the grammar was preferred over the lower rule since it
shifted the T_LPAREN instead of reducing unary_expression. Its
implementation invoked undefined behavior if the expression was NULL
since it didn't assign anything to $$.
The change in lex.c 1.129 attempted to add support for __alignof, in
addition to the existing support for __alignof__. It failed by removing
support for __alignof__, while allowing the plain 'alignof' instead.
Restore the grammar rule for labeled_statement as it was before cgram.y
1.400 from 2022-04-24. This allows labels with attributes again. Fix
the wrong interpretation in the tests; the attributes belong to the
label, not to the statement.
Today in the morning, when I thought that the change in cgram.y 1.400
were innocent, I accidentally ran lint only with the options '-Sw' but
forgot the option '-g' for GNU mode. Without that option, the token
'__attribute__' is unknown, which unsurprisingly leads to lots of syntax
errors, and these didn't change with that commit. The actual change was
only visible in GNU mode.
Seen in xsrc/LRGB.c:799.
Even though it looks like this lint error may have been introduced by
cgram.y 1.400 from 2022-04-24 (since LRGB.c has been unchanged for a
month), earlier versions of lint produce the same parse errors.
In indent.h 1.49 from 2021-10-25, the enumeration token_type was split
into lexer_symbol and parser_symbol to more clearly express that these
tokens fall into completely different classes of usage patterns.
On i386, the test failed because the warning in line 101 was not
generated. This was because size_t on i386 is unsigned int (see
arch/i386/targparam.h, SIZEOF_TSPEC). The result of the multiplication
had type unsigned int, and message 132 does not trigger for a conversion
from unsigned int to signed int because both types have the same size
(see check_integer_conversion, portable_size_in_bits).
Change the involved type from size_t (which the original code used) to
unsigned long long (which is uint64_t on all platforms supported by
lint), so that the warning is generated on all platforms in the same
way.
Noticed in lex.c, in the macro kwdef, where lint complains about the
condition containing '||' but not about the conditions containing only
'>' or '=='.
In msg_259_ilp32.c 1.6 from 2022-04-15, I removed the option -S from the
test in order to keep the message 259, but I forgot to fix the C99-style
comment as well.
In platform_int.c, the default lint option -S no longer generated
warning 259, so remove that option.
The options -t, -s and -S are confusing because they are used
inconsistently. The option -S enables C99 features, but when using it
instead of -s, it also doesn't enable all checks required by C90 and
later. Prepare fixing of these inconsistencies by replacing the flag
variables with language levels that can be extended in a
straight-forward way as new C standards arrive.
| option | allow_trad | allow_c90 | allow_c99 | allow_c11 |
|--------|------------|-----------|-----------|-----------|
| -t | x | - | - | - |
| (none) | x | x | - | - |
| -s | - | x | - | - |
| -S | - | x | x | - |
| -Ac11 | - | x | x | x |
Each usage of the old flag variables will be inspected and migrated
individually, to clean up the subtle variations in the conditions and to
provide a simpler model.
When lint was created in 1995, its focus was migrating traditional C
code to C90 code. Lint does not help in migrating from C90 to C99 or
from C99 to C11 since there are only few silent changes, and simply
because nobody took the time to implement these migration aids. If
necessary, such migration modes could be added separately.
There is a small functional change: when the option -s is combined with
either -S or -Ac11, lint now only keeps the last of these options.
Previously, these options could be combined, leading to a mixture of
language levels, halfway between C90, C99 and C11. Especially combining
traditional C with C11 doesn't make sense, but xlint currently allows
it.
The 3 tests that accidentally specified multiple language levels have
been adjusted to a single language level.
Message 259 is "argument #%d is converted from '%s' to '%s' due to
prototype", and it is intended to warn about compatibility between
traditional C where functions had no prototypes and standard C where
functions have prototypes.
Running lint in C99 mode is further away from traditional C than running
lint in C90 mode, so that warning doesn't make sense for C99. There are
still some inconsistencies in the 5 language version modes that lint
offers:
-t for traditional C
(no option) for migrating traditional C to C90
-s for C90 code
-S for C99 code
-Ac11 for C11 code
By disabling warning 259 in C99 mode, a typical NetBSD build produces
14.500 fewer warnings than before, of about 100.000 total.
Message 259 overlaps with message 298 "conversion from '%s' to '%s' may
lose accuracy, arg #%d", and in some cases of potentially lossy
conversions, lint now produces none of these messages. In some other
cases, these warnings were reported redundantly. The cases where
message 298 makes sense will be added back later, as needed.
The names membar_enter/exit were unclear, and the documentation of
membar_enter has disagreed with the implementations on sparc,
powerpc, and even x86(!) for the entire time it has been in NetBSD.
The terms `acquire' and `release' are ubiquitous in the literature
today, and have been adopted in the C and C++ standards to mean
load-before-load/store and load/store-before-store, respectively,
which are exactly the orderings required by acquiring and releasing a
mutex, as well as other useful applications like decrementing a
reference count and then freeing the underlying object if it went to
zero.
Originally I proposed changing one word in the documentation for
membar_enter to make it load-before-load/store instead of
store-before-load/store, i.e., to make it an acquire barrier. I
proposed this on the grounds that
(a) all implementations guarantee load-before-load/store,
(b) some implementations fail to guarantee store-before-load/store,
and
(c) all uses in-tree assume load-before-load/store.
I verified parts (a) and (b) (except, for (a), powerpc didn't even
guarantee load-before-load/store -- isync isn't necessarily enough;
need lwsync in general -- but it _almost_ did, and it certainly didn't
guarantee store-before-load/store).
Part (c) might not be correct, however: under the mistaken assumption
that atomic-r/m/w then membar-w/rw is equivalent to atomic-r/m/w then
membar-r/rw, I only audited the cases of membar_enter that _aren't_
immediately after an atomic-r/m/w. All of those cases assume
load-before-load/store. But my assumption was wrong -- there are
cases of atomic-r/m/w then membar-w/rw that would be broken by
changing to atomic-r/m/w then membar-r/rw:
https://mail-index.netbsd.org/tech-kern/2022/03/29/msg028044.html
Furthermore, the name membar_enter has been adopted in other places
like OpenBSD where it actually does follow the documentation and
guarantee store-before-load/store, even if that order is not useful.
So the name membar_enter currently lives in a bad place where it
means either of two things -- r/rw or w/rw.
With this change, we deprecate membar_enter/exit, introduce
membar_acquire/release as better names for the useful pair (r/rw and
rw/w), and make sure the implementation of membar_enter guarantees
both what was documented _and_ what was implemented, making it an
alias for membar_sync.
While here, rework all of the membar_* definitions and aliases. The
new logic follows a rule to make it easier to audit:
membar_X is defined as an alias for membar_Y iff membar_X is
guaranteed by membar_Y.
The `no stronger than' relation is (the transitive closure of):
- membar_consumer (r/r) is guaranteed by membar_acquire (r/rw)
- membar_producer (w/w) is guaranteed by membar_release (rw/w)
- membar_acquire (r/rw) is guaranteed by membar_sync (rw/rw)
- membar_release (rw/w) is guaranteed by membar_sync (rw/rw)
And, for the deprecated membars:
- membar_enter (whether r/rw, w/rw, or rw/rw) is guaranteed by
membar_sync (rw/rw)
- membar_exit (rw/w) is guaranteed by membar_release (rw/w)
(membar_exit is identical to membar_release, but the name is
deprecated.)
Finally, while here, annotate some of the instructions with their
semantics. For powerpc, leave an essay with citations on the
unfortunate but -- as far as I can tell -- necessary decision to use
lwsync, not isync, for membar_acquire and membar_consumer.
Also add membar(3) and atomic(3) man page links.
These tests run two threads for five seconds each to try to trigger
races in the event of broken memory barriers. They run only on
machines with at least two CPUs; on uniprocessor systems there's no
point -- the membars can correctly just be (instruction barrier)
no-ops.
The code in add_function is severely broken, it mixes up the return type
of the function with the argument types. For now, at least show the
guessed type in the diagnostic, to allow human readers quickly spot the
bug.
Extend the test cases in decl_direct_abstract.c to show that the
behavior differs unreasonably if the first parameter of the function is
equal to its return type.
The syscall only guarantees up to 256 bytes in a single go -- if
interrupted, it might return short, but if the caller requested at
least 256 bytes it will definitely return 256 bytes.
The warning is wrong, and it has been for a long time. For now just fix
the test to match the actual output. Seen on evbarm, which is one of
the platforms where a plain char is unsigned.
Noticed by Martin.
Previously, the string literals "1" "2" "3" "4" were concatenated in the
order "23", "234", "1234". This influenced the location of the
diagnostics for traditional C (which doesn't know concatenation at all)
and for mixing regular strings and wide strings.
Now the diagnostics occur exactly where they are expected. The first
string literal defines whether the whole string is regular or wide, and
any further string literals must match it.
In traditional C mode, there are more diagnostics than before, but that
doesn't hurt since they are still correct and nobody uses lint in
traditional C mode anyway.
This only applies to traditional C and ensures that the behavior is
preserved when rearranging the C parser to evaluate string concatenation
from left to right.
The commit that introduced the assertion failure looks innocent, it only
adds a few predefined functions for GCC mode. Nevertheless, before that
commit, lint consistently complained about 'error: void type illegal in
expression [109]', which doesn't make sense either.
This fix also removes the creative use of the initialization stack to
store the type of the statement expression. Having a separate stack for
these statement expressions makes the code easier to understand.
andvar