llvm-project

Commit Graph

Author	SHA1	Message	Date
Aaron Ballman	e765e0bc8e	Use functions with prototypes when appropriate; NFC A significant number of our tests in C accidentally use functions without prototypes. This patch converts the function signatures to have a prototype for the situations where the test is not specific to K&R C declarations. e.g., void func(); becomes void func(void); This is the first batch of tests being updated (there are a significant number of other tests left to be updated).	2022-02-03 16:42:27 -05:00
Serge Pavlov	dfdb731967	Limit number of bits in size representation so that bit size fit 64 bits. This fixes PR8256 and some others. llvm-svn: 186385	2013-07-16 07:14:18 +00:00
Douglas Gregor	caa1bf434d	Emit an error if an array is too large. We're slightly more strict than GCC 4.2 here when building 32-bit (where GCC will allow allocation of an array for which we can't get a valid past-the-end pointer), and emulate its odd behavior in 64-bit where it only allows 63 bits worth of storage in the array. The former is a correctness issue; the latter is harmless in practice (you wouldn't be able to use such an array anyway) and helps us pass a GCC DejaGNU test. Fixes <rdar://problem/8212293>. llvm-svn: 111338	2010-08-18 00:39:00 +00:00

Author

SHA1

Message

Date

Aaron Ballman

e765e0bc8e

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

  void func();

becomes

  void func(void);

This is the first batch of tests being updated (there are a significant
number of other tests left to be updated).

2022-02-03 16:42:27 -05:00

Serge Pavlov

dfdb731967

Limit number of bits in size representation so that bit size fit 64 bits.

This fixes PR8256 and some others.

llvm-svn: 186385

2013-07-16 07:14:18 +00:00

Douglas Gregor

caa1bf434d

Emit an error if an array is too large. We're slightly more strict

than GCC 4.2 here when building 32-bit (where GCC will allow
allocation of an array for which we can't get a valid past-the-end
pointer), and emulate its odd behavior in 64-bit where it only allows
63 bits worth of storage in the array. The former is a correctness
issue; the latter is harmless in practice (you wouldn't be able to use
such an array anyway) and helps us pass a GCC DejaGNU test.

Fixes <rdar://problem/8212293>.

llvm-svn: 111338

2010-08-18 00:39:00 +00:00

3 Commits