Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop/holland01 #7

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Conversation

holland01
Copy link

@holland01 holland01 commented Jun 3, 2018

Just support for MSVC. Note that ssize_t is a posix extension which Windows doesn't appear to support still.

base58.c Outdated
#ifdef _WIN64
typedef int64_t ssize_t;
#else
typedef int32_t ssize_t;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would prefer to just avoid ssize_t (use size_t and avoid circumstances that can lead to a negative value) rather than try to typedef it. Pretty sure this will break on Mingw.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm honestly wondering why ssize_t existed there in the first place, then?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Convenience; j can get to -1 with the current code. So we need to handle it differently to avoid that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved this issue to #8; please review

base58.c Outdated
#include <arpa/inet.h>
#else
#include <winsock2.h>
#include <malloc.h>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There doesn't seem to be any malloc.h on at least Mingw cross-compilers.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll replace with an appropriate _MSC_VER check.

#endif

#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still need stdint.h here, as this file uses intN_t types.

Copy link
Author

@holland01 holland01 Jun 3, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be included in files where it is used directly.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, fair enough.

@@ -5,19 +5,31 @@
* under the terms of the standard MIT license. See COPYING for more details.
*/

#ifndef WIN32
#include "libbase58.h"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this being moved?

Copy link
Author

@holland01 holland01 Jun 3, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stdint.h is in libbase58.h - see here.

stdint.h is needed in the header for msvc compilation.

I also didn't see any reason include 4 header files before the libbas58.h file, considering that most of those aren't necessary for the function declarations found in it.

base58.c Outdated
@@ -37,39 +49,69 @@ typedef uint32_t b58_almostmaxint_t;
#define b58_almostmaxint_bits (sizeof(b58_almostmaxint_t) * 8)
static const b58_almostmaxint_t b58_almostmaxint_mask = ((((b58_maxint_t)1) << b58_almostmaxint_bits) - 1);

// MSVC 2017 doesn't support the GCC (and probably clang) extension
// for dynamic arrays in C
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Variable length arrays are a standard C99 feature, not an extension. The library is intentionally designed to not use malloc/calloc/free.

Copy link
Author

@holland01 holland01 Jun 3, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Variable length arrays are a standard C99 feature, not an extension. The library is intentionally designed to not use malloc/calloc/free.

That may be, but MSVC still doesn't support them. _alloca or the MSVC _malloca can be used if that's preferred - these perform stack allocation (though _malloca will allocate heap for sufficiently large sizes).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, MSVC is a C++ compiler, not a C compiler.

I suppose it can't hurt to use _malloca or such, based on a failed configure check for standards compatibility...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few years back they added C99 support. It's still subpar in comparison to MinGW/GCC, but it's better than it used to be - enough to where people who like C end up using it over C++.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrote a simple alternative in #9; can you check if it works?

b58_maxint_t t;
b58_almostmaxint_t c;
size_t i, j;
uint8_t bytesleft = binsz % sizeof(b58_almostmaxint_t);
b58_almostmaxint_t zeromask = bytesleft ? (b58_almostmaxint_mask << (bytesleft * 8)) : 0;
unsigned zerocount = 0;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't mess with the formatting.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies, I'll be sure to omit any of those in the future.

luke-jr and others added 4 commits June 3, 2018 22:06
Detects j dropping below 0 going unchecked.
This bug was originally fixed in 2c6b791, but due to ssize_t being a POSIX extension, we are going to check it manually.
Only j could become negative, so we simply check before it would
@holland01
Copy link
Author

@luke-jr Ok, changes have been added. Please review

base58.c Outdated
#define b58_log_err(msg, ...) printf("[" __FUNCTION__ " - ERROR]: " msg, __VA_ARGS__)

#define b58_alloc_mem(type, name, count) \
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm honestly not sure what's up with the indentation of the escape slashes here. With invisibles in Atom turned on everything looks as if it's tabbed appropriately, and this is exactly how it looked before the push:

badformat

@jasny
Copy link

jasny commented Apr 3, 2019

@luke-jr 🏓

What is needed to merge this PR and fix the Windows build?

@luke-jr
Copy link
Member

luke-jr commented Apr 3, 2019

At the very least, a clean and reviewable branch...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants