Ensure that integers in native function definitions have fixed sizes

[ds5678]

This pull request ensures that all exported functions in the C++ headers use integers with exact bit-widths.

[ds5678]

@alinpahontu2912 Can you review this pull request?

[Copilot]

Pull request overview

This PR updates LibTorchSharp’s native C/C++ exported API surface to use fixed-width integer types (e.g., int32_t, int64_t, uint16_t) instead of platform-dependent types like int, long, and unsigned short, improving ABI stability across platforms and architectures.

Changes:

• Replaces many exported function parameters/return types from int/long to int32_t/int64_t across tensor, NN, JIT, FFT, vision, and torch utility APIs.
• Updates scalar/half conversion APIs to use uint16_t* instead of unsigned short*.
• Generalizes the toTensors helper to accept non-int length types.

Reviewed changes

Copilot reviewed 19 out of 19 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/Native/LibTorchSharp/Utils.h	Generalizes toTensors to accept a non-fixed length type.
src/Native/LibTorchSharp/THSVision.h	Uses fixed-width types for device identifiers in exported API.
src/Native/LibTorchSharp/THSVision.cpp	Aligns implementation signatures and uses int64_t for byte offset arithmetic.
src/Native/LibTorchSharp/THSTorch.h	Converts several exported APIs to int32_t and uint16_t*.
src/Native/LibTorchSharp/THSTorch.cpp	Aligns implementations with fixed-width signatures and casts.
src/Native/LibTorchSharp/THSTensorMath.cpp	Fixes exported parameter sizes (int32_t length, int64_t dims).
src/Native/LibTorchSharp/THSTensorFactories.cpp	Uses int32_t for device ids and array lengths in factories.
src/Native/LibTorchSharp/THSTensorConv.cpp	Converts many length parameters to int32_t and related helpers.
src/Native/LibTorchSharp/THSTensor.h	Broad fixed-width type sweep across exported tensor APIs.
src/Native/LibTorchSharp/THSTensor.cpp	Aligns exported implementations with updated fixed-width signatures.
src/Native/LibTorchSharp/THSRandom.cpp	Updates random tensor factory APIs to fixed-width lengths/device ids.
src/Native/LibTorchSharp/THSOptimizers.cpp	Updates optimizer ctor signatures to fixed-width list lengths.
src/Native/LibTorchSharp/THSNN.h	Updates NN exported APIs to fixed-width list lengths and indices.
src/Native/LibTorchSharp/THSNN.cpp	Aligns NN implementations with fixed-width length parameters.
src/Native/LibTorchSharp/THSModule.cpp	Updates module child access APIs (notably children_size).
src/Native/LibTorchSharp/THSLinearAlgebra.cpp	Updates linalg exported APIs to fixed-width lengths and mode type.
src/Native/LibTorchSharp/THSJIT.h	Updates JIT exported APIs to fixed-width lengths and counts.
src/Native/LibTorchSharp/THSJIT.cpp	Aligns JIT implementations with updated fixed-width signatures.
src/Native/LibTorchSharp/THSFFT.cpp	Updates FFT exported APIs to fixed-width *_length parameters and device ids.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The exported THSNN_Module_children_size implementation returns size_t, which is not an exact-width integer and changes size between 32-bit and 64-bit builds. To keep the native ABI stable (and aligned with the PR intent), use a fixed-width return type (e.g., int64_t/uint64_t) and cast children().size() before returning.

[ds5678]

keep the native ABI stable (and aligned with the PR intent)

Pointer-sized integer types are ABI stable and aligned with the intent of the pull request.

[Copilot]

THSNN_Module_children_size now returns size_t, which is platform-dependent (32-bit on x86, 64-bit on x64) and conflicts with the PR goal of fixed-size integers for exported APIs. Consider returning a fixed-width type (e.g., int64_t/uint64_t) and casting the children().size() result accordingly so the ABI is stable across platforms.

Suggested change

	EXPORT_API(size_t) THSNN_Module_children_size(const NNModule module);
	EXPORT_API(int64_t) THSNN_Module_children_size(const NNModule module);

[ds5678]

As I said in the other comment, there's nothing wrong with pointer-sized integers, especially when they most accurately reflect the native semantics.

[ds5678]

@alinpahontu2912 Is this good for merging?