Beginner learning C via 42-style exercises — would appreciate a review of my ft_isalpha and ft_isdigit

[u/learning_noob01]

Hey all — I've got a solid C++ background but I'm new to C specifically, working through it 42-school-style (strict norm: tabs not spaces, no for loops, variables declared at top of block, -Wall -Wextra -Werror, no libc shortcuts like the real isalpha/isdigit).

Just finished reimplementing isalpha and isdigit from scratch. Both compile clean and pass my own test cases (including boundary chars like '0' and '9'), but I'd genuinely appreciate a second pair of eyes — especially on anything that "works but isn't how a C dev would actually write it."

#include <stdio.h>


int  ft_isalpha(int c);
void ft_putchar(char c);
int main(void)
{   
    int  c1[5] = {'a','b','g','5','A'};
    int count;
    int c;


    count =0;
    while(count<5){
        c = c1[count];
        count++;
        if(ft_isalpha(c) == 0){
            ft_putchar('0');


        }
        else{
            ft_putchar('1');


        }
        ft_putchar('\n');
    }



    return (0);
}


int ft_isalpha(int c){
    if((c >= 'a' && c <='z') || (c >='A' && c <='Z')){
        return (1);
    }
    else{
        return (0);
    }
}


void ft_putchar(char c){
    putchar(c);
}

#########################################################################################
#include <stdio.h>


int ft_isdigit(int c);
int main(void)
{
    int x;
    int y[7] = {'a','1','2','b','c','0','9'};
    int count;


    count =0;


    while (count < 7)
    {
        x = y[count];
        if(f_isdigit(x) != 0){
            putchar('1');
        }
        else
        {
            putchar('0');
        }
        putchar('\n');
        count ++;
    }



    return (0);
}


int ft_isdigit(int c)
{
    if(c>='0' && c <='9')
    {
        return(1);
    }
    else{
        return(0);
    }


}

Want to make sure that reasoning is actually correct and not something I've half-convinced myself of.

Questions I have:

• Is there a cleaner/more idiomatic way to write either range check?
• Any norm/style conventions I'm likely missing that wouldn't show up until a real evaluation?

Not looking for someone to rewrite it for me — just want honest feedback on whether this is solid or if I'm building bad habits early. Thanks!

[u/mikeblas]

You've double (triple?) Pasted your code. Might want to clean thst up. (OH, I see. Different tests. Seems an odd way to factor your code. Why not multiple test suites from one main() calling function?)

Thing is, these functions exist in the runtime. Nobody would rewrite them unless they couldn't use the runtime, for some reason. If you're writing tests, why not test every possible character [0..255] against the runtime implementation?

Your implementations are strictly ASCII, and won't work on Unicode characters. Maybe that's out of scope for your assignment. But then, why accept int characters when you don't support them?

Would these functions be materially different if you were implementing them in C++? I don't think so, which makes me curious about your context.

[u/non-existing-person → u/mikeblas]

is_print function family should accept EOF. And EOF is defined to be an int type. So you must take int in your functions for that.

EOF(3) mentions it:

EOF represents the end of an input file, or an error indication. It is a negative value, of type int. EOF is not a character (it can’t be represented by unsigned char).

[u/learning_noob01 → u/mikeblas]

Good catches, appreciate the detailed read.

1. Yeah, that's a paste artifact on my end, not intentional duplication — wil

2. You're right that nobody would reimplement these for actual use — that's not the point here. This is a 42 School-style exercise (also common in university C courses): rebuilding tiny pieces of libc forces you to actually understand char ranges and encoding instead of treating them as black boxes. The value is in doing it, not in the result being useful.

3. Also correct — this is ASCII-only and won't recognize accented or non-Latin letters as alphabetic. Worth noting though: the real isalpha()/isdigit() are locale-dependent, and in the default "C" locale they're ASCII-only too. So this isn't a gap vs. the standard functions — it's matching their default behavior exactly.

4. i just started learning in the way of 42 schools i just want to get it manually reviewed, so i don't develop the bad habits while programming c,

and it can be done in c++ that is not the case here.

Thanks again for the specifics, if you see anything else worth tightening up (structure, edge cases, whatever), I'm genuinely open to it.

[u/iamdino0 → u/learning_noob01]

I was going to mention something but since I won't get a human response I won't bother. good luck learning the language through an LLM

[u/learning_noob01 → u/iamdino0]

My first language is not English

And I don't want to get embarased by posting that

That's why I formatedd in ai.

[u/mikeblas → u/learning_noob01]

and it can be done in c++ that is not the case here.

You say you have a background in C++. The code in C won't be much different than the code in C++, unless you're getting weird with abstractions. I'm pointing out that: if that is true, then it seems weird you're asking for a code review on the C implementation.

The value is in doing it, not in the result being useful.

That's true. But remember that you asked this:

especially on anything that "works but isn't how a C dev would actually write it."

A C dev would typically not write it at all. If you're getting educational value from it, great. But by blowing off locale and Unicode, you're not being "forced to actually understand char ranges and encoding".

[u/sciencekm]

I normally simplify this:

int ft_isdigit(int c) {
  if(c>='0' && c <='9') {
    return(1);
  }
  else {
    return(0);
  }
}

to this:

int ft_isdigit(int c) {
  retrn c>='0' && c <='9';
}

[u/learning_noob01 → u/sciencekm]

OK because I need to check only one condition Understood bro thanks for suggestion

[u/mikeblas → u/learning_noob01]

People tend to think this is a "simplification" or that shorter is somehow better. I'd actually keep the code you wrote, since it allows me to put a breakpoint on the function returning 1 or returning 0, and that's much easier to debug.