fix C99-style declarations

Although the compiler has always supposed C99 style, I feel that until the kernel as a whole moves to C99 style, such code reduces portability to other compilers. In particular, I am willing to bet Intel's Yamhill will eventually be supported by the x86-64 code, and non-gcc compilers will eventually be used to build this platform.

# --------------------------------------------
# 03/10/25 [email protected] 1.1351
# [AMD64] Fix C99-ish mix of declarations and code. # --------------------------------------------

diff -Nru a/arch/x86_64/ia32/syscall32.c b/arch/x86_64/ia32/syscall32.c
@@ -30,10 +30,12 @@
 int map_syscall32(struct mm_struct *mm, unsigned long address) 
 { 
 	pte_t *pte;
+	pmd_t *pmd;
 	int err = 0;
+
 	down_read(&mm->mmap_sem);
 	spin_lock(&mm->page_table_lock); 
-	pmd_t *pmd = pmd_alloc(mm, pgd_offset(mm, address), address); 
+	pmd = pmd_alloc(mm, pgd_offset(mm, address), address); 
 	if (pmd && (pte = pte_alloc_map(mm, pmd, address)) != NULL) { 
 		if (pte_none(*pte)) { 
 			set_pte(pte, 

diff -Nru a/arch/x86_64/kernel/bluesmoke.c b/arch/x86_64/kernel/bluesmoke.c
@@ -200,11 +200,14 @@
 static void check_k8_nb(int header)
 {
 	struct pci_dev *nb;
+	u32 statuslow, statushigh;
+	unsigned short errcode;
+	int i;
+
 	nb = find_k8_nb(); 
 	if (nb == NULL)
 		return;
 
-	u32 statuslow, statushigh;
 	pci_read_config_dword(nb, 0x48, &statuslow);
 	pci_read_config_dword(nb, 0x4c, &statushigh);
 	if (!(statushigh & (1<<31)))

@@ -215,7 +218,7 @@
 	printk(KERN_ERR "Northbridge status %08x%08x\n",
 	       statushigh,statuslow); 
 
-	unsigned short errcode = statuslow & 0xffff;	
+	errcode = statuslow & 0xffff;	
 	switch (errcode >> 8) { 
 	case 0: 					
 		printk(KERN_ERR "    GART TLB error %s %s\n", 

@@ -249,7 +252,6 @@
 	/* should only print when it was a HyperTransport related error. */
 	printk(KERN_ERR "    link number %x\n", (statushigh >> 4) & 3);
 
-	int i;
 	for (i = 0; i < 32; i++) 
 		if (highbits[i] && (statushigh & (1<<i)))
 			printk(KERN_ERR "    %s\n", highbits[i]); 

diff -Nru a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c
@@ -332,6 +332,7 @@
 void __init setup_arch(char **cmdline_p)
 {
 	unsigned long low_mem_size;
+	unsigned long kernel_end;
 
  	ROOT_DEV = old_decode_dev(ORIG_ROOT_DEV);
  	drive_info = DRIVE_INFO;

@@ -380,7 +381,6 @@
 				(table_end - table_start) << PAGE_SHIFT);
 
 	/* reserve kernel */
-	unsigned long kernel_end;
 	kernel_end = round_up(__pa_symbol(&_end),PAGE_SIZE);
 	reserve_bootmem_generic(HIGH_MEMORY, kernel_end - HIGH_MEMORY);
 

The intel compiler supports C99 just fine.

x86-64 always used C99 and there is no x86-64 compiler around that doesn't support it. I must say I was somewhat pissed off that someone added that nasty warning to the toplevel Makefile just to comfort some gcc 2.95 users on i386 ("all world is a i386")

I have enough trouble just to get the essential bug/compilefixes accepted by Linus, so I see no chance to get such things in currently.

-Andi

Sorry, that is bullshit. The change was entirely designed to prevent people on such architectures hacking general files where there *do* exist older compilers, to avoid breakage being introduced without it being flagged.

This has happened more than once in the tree.

When all the architectures have a minimum gcc requirement that accepts mixed code and declarations by default, it can be removed ...

regards,
john

Khendon's Law:
If the same point is made twice by the same person, the thread is over.

I don't think it makes much difference. People hacking on one architecture break other architectures all the time for various reasons, e.g. the implicit includes in different architectures vary widely.

The few people left who use 2.95 will just have to live with occasional breakage when they insist on using a non standards compliant compiler.

Would be my prefered solution. Discourage 2.95.

Sooner or later we have to do that anyways when a bug in 2.95 is found that breaks code (has happened with all gccs so far). Sooner would be better, as supporting 2.95 seems to be already a significant mainteance burden.

-Andi

An unusual argument ...

I am a little dubious it's "few people". (especially as gcc 2.96 has the same problem).

regards,
john

Khendon's Law:
If the same point is made twice by the same person, the thread is over.

Hi!

Well.. except that 2.95 is still two times faster than gcc 3.3 :-(.

Pavel

When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]